New Star Software Collection/NSS_Collection.iso/3-069 qemm 603/1.ima/DVMAN/APPEND-H.DEV

Text File | 1991-10-08 | 5.9 KB | 115 lines

Appendix H

More About What Programs Run in DESQview

 Most programs that run under DOS will run in DESQview. In general, programs
that interface to the hardware using DOS or ROM BIOS calls will run more
successfully in DESQview than programs that deal directly with the hardware.
However, Quarterdeck has made every effort to accommodate the anomalous
behavior of all programs we have evaluated.

Potential incompatibilities between programs and DESQview can be grouped into
the following categories: memory management, screen management, and keyboard
management.

~Subhead~ Memory Management

 Programs are expected to conform to the standard DOS conventions for
determining their memory size and their location in memory.  They should
either inspect offset 02H in their program prefix or use the ROM BIOS memory
check call (interrupt 12H) to find the maximum address they're allowed to
reference. If a program assumes that it will run in a particular area of
memory or that it can use memory above that allowed by DOS, it won't run in
DESQview. (See Appendix B for information on programs that use EMS or EEMS
memory.)

~Subhead~ Screen Management

 DESQview can manage screen writes in small windows and in background under
the following three circumstances:

~Item~ Programs that display character-based information on the screen by
calling DOS or the ROM BIOS run in small DESQview windows and in background.

~Item~ Programs that are DESQview aware, meaning they're customized for
DESQview by the program developer or by Quarterdeck, will run in small
windows and in background.

~Item~ Programs running inside DESQview 386 which can be virtualized (See
Appendix K) can run in small windows and background.

 Otherwise programs can run in full-screen-only windows only and cannot run
in background. This includes programs that write directly to the screen which
are running on 8088, 8086 or 80286 PCs. Although you cannot "run" a
full-screen-only program in a small window, you can "view" (and scroll) the
program in a small window. When you place a full-screen-only program in a
small window, it's suspended until you zoom it back to full-screen.

If a program switches into graphics mode, it should do so using the standard
ROM BIOS interrupt 10H interface and must be installed with the Displays
graphics information option set to ON. While in graphics mode, if the program
is not being virtualized, it runs in a full-screen-only window. If you place
a full-screen-only graphics program in a small window, the graphics
information can be viewed but the program will be suspended.

~Subhead~ Printer Management

 If two programs attempt to write to the same print device simultaneously, a
conflict can arise. See Appendix A for information on how to set up DESQview
to resolve such conflicts for you.

~Subhead~ KeyboardManagement

 Programs that call DOS or the ROM BIOS to receive keyboard input can  always
learn scripts successfully. However, whether scripts play back properly
depends on how the program handles type-ahead.  Some programs always allow
type-ahead, and some never allow it. The most common case is that type-ahead
is allowed most of the time~dash~such as when you're entering data~dash~but
not all of the time. You can control how DESQview handles type-ahead when it
plays back a script by setting the Keyboard Conflict level.

 Some programs bypass DOS and the ROM BIOS and read the keyboard directly.
Such programs will often still run in DESQview, but you'll be unable to learn
or perform DESQview scripts or to transfer information into them. Set the
Keyboard Conflict level to 4 or higher for such programs. See page 131 for a
discussion of each keyboard conflict setting.

~Subhead~ File Management

 DESQview doesn't interfere with normal DOS file operations except to provide
a Logical Drive mapping facility (see Appendix A) and to map files named
DESQTMP?.* to the DV directory. This is useful for creating mark and transfer
scripts since it allows a program to write a file that always goes into a
known directory, independently of the directory in which the program is
running. Any program using standard DOS file management should run without
problems in DESQview. You must be careful, however, that two programs don't
use the same file at the same time or that a program, running in two
different windows, doesn't use a fixed temporary file name.

~Subhead~ Communications Management

 Communications programs generally attach themselves directly to the
communications port's interrupt vectors. DESQview does not interfere with
these connections, thereby allowing the program to run in background. A
program connected to these vectors should usually be installed with the Can
be swapped out of memory option OFF (See page 210, Appendix E for an
exception to this.) If Uses Serial Ports is set to "Y" (meaning all ports a
program uses) or a specific COM port number, it will not be swapped out
(unless specifically told to do so).

 To help manage serial port communications, DESQview sets ROM BIOS locations
40H:00H and 40H:02H to zero for any program whose Uses Serial Port option is
set to NO. This indicates that communications ports 1 and 2 are unavailable
. COM3 (40H:04H) and COM4 (40H:06H) are not hidden in this way. The correct
port address values are left in place if this option is ON (Y, 1 or 2) If
there is a problem with a program accessing an unwanted COM port, reference
a specific port in the Change a Program menu, which will "hide" other COM
ports from the program. This only works for programs which access the BIOS
data area to determine the status of the COM port and not for programs which
directly access the hardware. A program that directly accesses the hardware
will find a serial port anyway.

 If you use a communications program and also have a mouse that attaches to
a communications port, you must be sure to attach each to a different port,
and to tell DESQview about each, via the Setup program.